Add resolved-dependency override mechanism for DR-008 by Subramanian-K812 · Pull Request #278 · eclipse-score/reference_integration

Subramanian-K812 · 2026-07-03T08:30:57Z

DR-008: resolved-dependency resolve + override mechanism (PR 1 of 2)

Part of #264. This is the first of two PRs that split the original DR-008 Option 4 change. This PR
adds the mechanism; the follow-up PR wires it into the test workflow.

What this PR does

Adds ResolvedDependencies — the mechanism DR-008 Option 4 needs to (1) resolve the full integrated
dependency set at the reference_integration root and (2) override those resolved versions directly
into an individual module.

Resolve (root): merges the override directives ref_int actually declares (MODULE.bazel +
bazel_common/*.MODULE.bazel) with the post-MVS registry versions from
bazel mod graph --output=json, and serializes the result to a single resolved_versions.json
manifest (--export / from_mod_graph / to_file). 156 modules today.
Override (into a module): scans a module's MODULE.bazel for every declared bazel_dep and
appends a git_override / single_version_override for each one we have a resolved version for,
so the module builds/tests against the resolved set (scan / overwrite). Injection is
append-only and idempotent (marked with begin/end comments), always skips the module-under-test
itself (the root is never overridden), always overwrites any dependency the module already
declares an override for (ref_int's resolved version always wins), and is never committed back to
module sources. A declared dependency with no entry in the resolved set is left to resolve on its
own and logs a warning.
Patch (into a module): module_patches.py applies the module-under-test's own declared
bazel_patches to its checkout by filesystem path (git apply -p1), before override injection —
a patch may add a bazel_dep that injection must not then duplicate. Distinct from the strip
above: that one drops bazel_patches from injected dependency overrides (their labels don't
resolve inside another module's checkout); this one is the module-under-test's own patches, which
name real files in ref_int's tree regardless of whose checkout is root. A patch that fails
git apply --check is a named, loud failure — attributed as a ref_int defect — never a silent
skip.
Guard (ref_int's own config): rc_label_consistency.py is an offline check that ref_int never
sets the same build-setting label at two different paths across its own .bazelrc,
ci/stage2/module.bazelrc (added by the follow-up PR), and known_good.json's
extra_test_config entries — catches a relocated upstream package before it surfaces as an
unrelated-looking Stage 2 failure, rather than after.
Report: the export also writes a resolved_pins_report.json sidecar recording, per pin,
whether ref_int explicitly asserted it or only inherited it from MVS, whether any consumer in
ref_int's own graph wanted a different version, and any override ref_int declares that could not be
carried into the manifest at all (today: rules_boost's archive_override). Nothing here changes
what gets pinned or fails the export — it makes the existing resolve step's decisions visible.

While testing this against a real checkout it turned up that rules_oci was silently falling out of
the manifest entirely (its git_override pinned a mutable tag, which can't become a manifest entry,
and nothing warned about it) — fixed by pinning it to a commit instead.

Files

File	Change
`scripts/known_good/resolved_dependencies.py`	New — the `ResolvedDependencies` mechanism (resolve + override + report) + CLI
`scripts/known_good/module_patches.py`	New — applies a module-under-test's own `bazel_patches` to its checkout ahead of override injection
`scripts/known_good/rc_label_consistency.py`	New — offline guard against ref_int naming one build setting at two different label paths
`scripts/known_good/tests/test_resolved_dependencies.py`	New — 67 self-contained unit tests (no cloned repos / Bazel needed)
`scripts/known_good/tests/test_module_patches.py`	New — 11 self-contained unit tests (throwaway git checkout + patch fixtures, no network)
`scripts/known_good/tests/test_rc_label_consistency.py`	New — 9 unit tests, plus a live-tree check that ref_int's actual config is consistent today
`scripts/known_good/BUILD`	New — `py_library :known_good`, `py_binary :resolve_deps` (Bazel-runnable), and `score_py_pytest :known_good_tests` so the unit tests run under Bazel
`.github/workflows/internal_tests.yml`	Modified — runs `:known_good_tests` in CI
`bazel_common/score_images.MODULE.bazel`	Modified — `rules_oci` pinned by commit instead of tag
`bazel_common/score_test_artifact_versions.MODULE.bazel`	New — asserts the versions of the three deps Stage 2 collects test artifacts from (`googletest`, `rules_rust`, `score_toolchains_rust`); no build change today
`MODULE.bazel`	Modified — `include()`s the file above
`MODULE.bazel.lock`	Modified — mechanical consequence of the pin above

Follow-up (PR 2)

The two-stage test_and_docs.yml (Stage 1 resolves + exports the manifest; Stage 2 checks out each
module, overrides deps via this mechanism, and runs its UT + coverage; then aggregates), the
module-context quality_runners.py, the dependency pin bumps, and the associated config all land in
the follow-up PR, which is stacked on this one.

github-actions · 2026-07-03T08:56:56Z

The created documentation from the pull request is available at: docu-html

a-zw · 2026-07-03T12:42:34Z


+# Alias: expose resolve_deps under //scripts/tooling for `bazel run //scripts/tooling:resolve_deps`.
+alias(
+    name = "resolve_deps",


Why this alias? This is usually for backwards-compatibility but since this is new functionality it should not be necessary.

The alias under //scripts/tooling provides reachability alongside other entry points. The implementation itself remains in //scripts/known_good since that’s where its models and tests live. The pipeline continues to call //scripts/known_good:resolve_deps directly; the alias simply exposes it without duplicating the target.

a-zw · 2026-07-03T12:48:42Z

+"""Unit tests for ResolvedDependencies (DR-008 Option 4 dependency injection).
+
+Self-contained: builds the resolved set from a temporary known_good.json and
+overwrites a temporary module MODULE.bazel — no cloned repos or Bazel required.


I like this self-contained aspect. It allows to use this in an hermetic way.

However, the tradeoff is that we cannot parallelize the followup actions (build, test, docs, etc) via GitHub actions, can we?

No, they can still run in parallel. Stage 1 resolves once and uploads resolved_versions.json as an artifact; each Stage 2 module job downloads that same artifact and does its own local override + build/test independently, still as a normal parallel matrix. The hermetic is only about the unit tests not needing real clones/bazel to validate scan()/overwrite() — it doesn't force any job serialization in the actual pipeline.

OliverHeilwagen

Please fix transitive dependency pinning gap

OliverHeilwagen · 2026-07-29T19:45:35Z

+import sys
+from pathlib import Path
+
+_HERE = Path(__file__).resolve().parent


Please make use of BUILD_WORKING_DIRECTORY or BUILD_WORKSPACE_DIRECTORY environment variable instead.

Please use repo_root in case mod_graph is not a absolute path e.g.;

if not mod_graph.is_absolute(): mod_graph = repo_root / mod_graph

Please apply the same pattern to export otherwise the files are only written to runfiles dir.

OliverHeilwagen · 2026-07-29T20:57:19Z

+    if args.resolved_deps:
+        resolved = ResolvedDependencies.from_resolved_artifact(args.resolved_deps)
+    else:
+        resolved = ResolvedDependencies.from_known_good(args.known_good_path)


Transitive dependency pinning gap

overwrite() only injects overrides for modules the module-under-test directly declares
via bazel_dep. Transitive dependencies silently fall through to MVS resolution, which may
pick a different version than what ref_int validated against.

Example:

ref_int (resolved: flatbuffers @ 25.12.19) └── communication (module under test) └── bazel_dep(name = "score_baselibs") ← override injected ✅ └── flatbuffers ← transitive, NO override injected ❌ MVS picks its own version

Fix: For every module in the resolved set that is not directly declared by the
module-under-test, inject both a bazel_dep stub and the override into the injection block:

# brings the transitive dep into the root graph so the override is valid bazel_dep(name = "flatbuffers", version = "0.0.0") git_override(module_name = "flatbuffers", commit = "...", remote = "...")

This also means from_known_good is insufficient for the inject mode, as it only carries
first-party score modules and has no transitive registry versions; --resolved-deps (from the
Stage-1 manifest) must be the required source for Stage 2 injection.

In Stage-1 we should also takeover and store the given graph.json as it is needed for Stage-2 to be aware of the necessary transitive overrides for a given MODULE.bazel file. Identification can be done via regex for module(name = "...").

… markers, simplify imports

…directive inline, add BUILD for bazel run

…wn_good.py, and tooling BUILD format

…wn_good tests

…ing it, and make resolved_dependencies importable standalone

…own MODULE.bazel

…nstead of only its declared deps

…icts, and drops

…raphs

…label consistency guard

PiotrKorkus · 2026-08-24T11:32:51Z

Hi @OliverHeilwagen, there was a discussion in todays SCORE alignment call and we decided to enable this workflow in parallel to the old integration tests. This will allow us to verify and tackle all the issues with the workflow itself in the transition period as pull_request_target does not allow to run it directly in the PR. On top of that, the changes are big and started to get messy - it will be easier to fix and review in separate PRs.

I will let myself merge this PR to enable rebase in #280 and adding this DR8 as parallel workflow. Please do not hesitate to continue reviewing in the part 2 PR or creating the issues directly. Thank you for contributing to the review!

OliverHeilwagen · 2026-08-24T11:38:17Z

@PiotrKorkus Thanks for the info, i will bring my pending comments over to #280 and continue the review there.

Subramanian-K812 force-pushed the Subramanian-K812_resolve_override_mechanism branch from 6d78316 to fbc58a3 Compare July 3, 2026 08:31

a-zw reviewed Jul 3, 2026

View reviewed changes

Subramanian-K812 force-pushed the Subramanian-K812_resolve_override_mechanism branch from e32b107 to cff77c1 Compare July 24, 2026 06:56

OliverHeilwagen suggested changes Jul 29, 2026

View reviewed changes

Subramanian-K812 force-pushed the Subramanian-K812_resolve_override_mechanism branch from cff77c1 to fce6a51 Compare August 3, 2026 03:10

Subramanian-K812 force-pushed the Subramanian-K812_resolve_override_mechanism branch from 36fe2e9 to fb20ff4 Compare August 11, 2026 10:22

Subramanian-K812 force-pushed the Subramanian-K812_resolve_override_mechanism branch from eda7170 to 5d9963e Compare August 21, 2026 05:37

Subramanian-K812 added 16 commits August 24, 2026 16:23

feat: add DR-008 resolved-dependency resolve + override mechanism

8e389bf

fix: remove bazel_config, always overwrite overrides, clean injection…

5a04b40

… markers, simplify imports

fix: revert update_module_from_known_good.py, move generate_override_…

b7e7f69

…directive inline, add BUILD for bazel run

fix: ruff format fix for scripts/tooling/BUILD

c20460d

fix: revert out-of-scope changes to module.py, update_module_from_kno…

a388b1f

…wn_good.py, and tooling BUILD format

feat: warn on unresolved declared deps, add bazel test target for kno…

376cd1b

…wn_good tests

fix: overwrite() replaces a module's own override instead of duplicat…

f72a9ef

…ing it, and make resolved_dependencies importable standalone

feat: reach one level of transitive git_override deps via a module's …

f1afd65

…own MODULE.bazel

feat: pin a module's full transitive closure from the Stage-1 graph i…

33df9a6

…nstead of only its declared deps

fix: key the Stage-2 pin scope on ref_int's resolved set

8407ad8

feat: lock the versions of deps Stage 2 collects test artifacts from

e336ba0

fix: pin rules_oci by commit and report every pin's provenance, confl…

5bce4be

…icts, and drops

fix: correct stale claims in comments

d72eaa7

fix: match Bazel's version ordering exactly and surface non-verbose g…

4401c58

…raphs

fix: resolve resolve_deps CLI paths

b3facb9

feat: apply module-under-test's own bazel_patches in Stage 2, add rc …

5b4774b

…label consistency guard

Subramanian-K812 force-pushed the Subramanian-K812_resolve_override_mechanism branch from 841b5fc to 5b4774b Compare August 24, 2026 10:53

Subramanian-K812 marked this pull request as ready for review August 24, 2026 10:53

Subramanian-K812 requested review from PiotrKorkus, nradakovic and pawelrutkaq as code owners August 24, 2026 10:53

Subramanian-K812 requested review from AlexanderLanin, FScholPer, MaximilianSoerenPollak, antonkri, dcalavrezo-qorix, lurtz and opajonk as code owners August 24, 2026 10:54

PiotrKorkus approved these changes Aug 24, 2026

View reviewed changes

PiotrKorkus requested a review from OliverHeilwagen August 24, 2026 11:27

PiotrKorkus merged commit 535763f into eclipse-score:main Aug 24, 2026
16 checks passed

Uh oh!

Conversation

Subramanian-K812 commented Jul 3, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

DR-008: resolved-dependency resolve + override mechanism (PR 1 of 2)

What this PR does

Files

Follow-up (PR 2)

Uh oh!

github-actions Bot commented Jul 3, 2026

Uh oh!

a-zw Jul 3, 2026

Choose a reason for hiding this comment

Uh oh!

Subramanian-K812 Jul 6, 2026

Choose a reason for hiding this comment

Uh oh!

a-zw Jul 3, 2026

Choose a reason for hiding this comment

Uh oh!

Subramanian-K812 Jul 6, 2026

Choose a reason for hiding this comment

Uh oh!

OliverHeilwagen left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

OliverHeilwagen Jul 29, 2026

Choose a reason for hiding this comment

Uh oh!

OliverHeilwagen Aug 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Subramanian-K812 Aug 21, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

OliverHeilwagen Jul 29, 2026

Choose a reason for hiding this comment

Uh oh!

PiotrKorkus commented Aug 24, 2026

Uh oh!

Uh oh!

OliverHeilwagen commented Aug 24, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Subramanian-K812 commented Jul 3, 2026 •

edited

Loading

OliverHeilwagen Aug 20, 2026 •

edited

Loading